Talk:Ray-tracing hardware

	This article is within the scope of WikiProject Computer graphics, a collaborative effort to improve the coverage of computer graphics on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.Computer graphicsWikipedia:WikiProject Computer graphicsTemplate:WikiProject Computer graphicscomputer graphics articles
Low	This article has been rated as Low-importance on the project's importance scale.

Computing

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
???	This article has not yet received a rating on the project's importance scale.

Proposed merges

SaarCOR and RPU should be merged and redirect to this article - articles cover research projects, not final products - there is at least as much info in this article as there are in the separate articles on the specific items.Shortfatlad (talk) 14:05, 27 February 2010 (UTC)[reply]

I do agree with the merge, especially on SaarCOR, because there aren't any citations yet. But I'm not sure about the other one, as it's a disambiguation page. Minima c (talk) 14:07, 27 February 2010 (UTC)[reply]

For RPU I meant the Ray Processing Unit page - didn't notice the link was to a disambig.Shortfatlad (talk) 16:21, 27 February 2010 (UTC)[reply]

Comparison to rasterization

"Whilst the complexity of the computation for rasterization scales linearly with number of triangles[5][note 3] the complexity of a properly implemented ray tracing algorithm scales logarithmically;[note 4] this is due to objects (triangles and collections of triangles) being placed into BSP trees or similar structures, and only being analyzed if a ray intersects with the bounding volume of the binary space partition."

IMHO this could mislead the reader, if taken as a comparison to the alternative hardware approach ( current mainstream GPUs, which are rasterization based). While rasterization itself does scale linearly, that isn't where the bulk of graphics time is spent in modern games (which are the leading edge drivers of GPU performance). See Z-buffering, Deferred shading#Deferred lighting in commercial games, and Tiled rendering for techniques that restrict the exposure to linear-scaled algorithms.
Also, its rather odd to see BSP trees mentioned as a benefit of ray tracing when compared to rasterization, since BSP trees are an essential part of all modern (rasterization based) game engines. As discussed in BSP trees / Overview, final paragraph.
Bottom line: while the statement is true, in a narrow sense, it needs more context, to be helpful rather than misleading. I'm not sure I know enough to attempt to rewrite it, so for now I'll just comment on it, in hopes this inspires someone else to do so...
I see that "Note 5" mentions that BSP can be used with rasterization, but only to reduce to the viewing frustrum. Again, true but misleading. That's what z-buffer helps with. Yes, the BSP only takes one so far, but combined with a z-buffer makes rasterization cheap: the only "linear" algorithm (in the sense of needing to be applied to ALL polygons in the viewing frustrum) is per-pixel depth calculation. The EXPENSIVE operations (texture lookup, lighting) can, at least in theory, only be done for visible pixels of visible polygons. E.g. identical to what is claimed as one advantage of ray-tracing. IMHO, no longer a significant advantage for ray-tracing. ToolmakerSteve (talk) 08:29, 23 October 2012 (UTC)[reply]

After further thought, I have marked the statement as POV, despite the notes that attempt to lessen its POV-ness. Reason: The paragraph compares the simplest possible implementation of rasterization, to "a properly implemented" ray tracer. This is not an apples to apples comparison. I think that anyone involved in a modern rasterizer-based engine, whether hardware or software, would take issue with that comparison. Hence, it is probably not NPOV. I do understand the point being made: the logarithmic solution for ray tracing comes readily; approaching logarithmic for rasterizers requires other complex techniques. And yes, the rasterization itself will still be linear. But, a "properly implemented" GPU based on rasterization will NOT display linear metrics for a scene of interesting complexity. And this is truer and truer every year. ToolmakerSteve (talk) 08:56, 23 October 2012 (UTC)[reply]

Having pondered the issue some more, I now believe that the mentioned sentences should be DELETED. Consider a dynamically changing scene. Whether performance degrades towards linear has everything to do with the quality of one's culling approach (e.g. how quickly one can modify the BSP-tree) -- and little or nothing to do with whether one is using rasterization or ray tracing. Perhaps the sentences could be replaced with a mild claim that ray tracing can make more effective use of BSP-based culling, because the volume of interest can be a single ray, rather than the view frustrum. However, I feel that there is NO justification for talking about linear versus logarithmic performance. If I'm going on a long journey, I don't care if my car can instantaneously teleport itself to the end of my street; what I care about is the car's performance over the whole trip. It is technically useful to be aware that ray-tracing has a specific benefit in relation to BSP-tree culling. It is misleading to make a broad statement about performance. If this was an article about the performance benefits of BSP-tree culling, then the performance claim might be appropriate. ToolmakerSteve (talk) 12:25, 23 October 2012 (UTC)[reply]

Yes. The paragraph compares the simplest possible implementation of rasterization, to "a properly implemented" ray tracer - you nailed it. I actually wrote this article several years ago, and have long since ceased editing, but happened across this old page by chance.

I take the point - and have removed the comparison. eg diff

As I noted before - newer API rasterisation methods such asDirectX 10 D3D10_QUERY_OCCLUSION_PREDICATE or OpenGL 3.0 HP_occlusion_query can help cull BSP volumes better than a simple frustrum cull (and better than linear)- especially if you add code to try to process the ~~object's~~ scene's BSP spaces in order roughly "near front to far back" order.. - works better on "inside" or "hilly" scenes and poorly on scenes with fractally structures eg trees..).

I plead out of date info, not an intention to mislead ;) ..

It's possible that other parts may need altering, or modifying - eg I wrote "shadows are difficult [to compute]" this before deferred rendering was commonly implemented in commercial software (ie games) - nowadays it is almost a standard.. Subjectively it could be said that the the term "difficult" is no longer accurate.83.100.174.82 (talk) 01:33, 31 July 2013 (UTC)[reply]